I just uploaded a minor update of Pyroman to unstable and the pyroman download page on alioth. I added support for a complete interface wildcard, and added example configuration files for a single-host setup. Pyroman is a firewall configuration tool I wrote for managing the firewall of a small network consisting of four zones and servers with a dozen different tasks. It plays very well in setups with DMZ, wireless networks, intranet etc. and all kinds of different services. Key benefits are the very simple syntax, safeguards (extensive syntax checks, rollback on failure, safety timeout option for remote administration), scriptability in python and high performance, since it does not run dozens of iptables commands, but generates a script file for iptables-restore. For more benefits, see the pyroman homepage. The next version will probably feature an XML syntax additionally; while the current Python syntax is very powerful and readable, it's pretty much impossible to write a GUI for editing the policy when written this way. That's why I'd like to add an XML syntax (that can be intermixed with Python statements, but only the XML-defined parts will be editable in the GUI) that supports the key parts of configuration (if you want the rules to be generated on the fly from some database or whatever, you'll still be able to do that in Python!): making it easier to write a GUI for it.

Dear Santa Pyro,
I've been a really good maintainer this year and I hope not to get coal. Don't let my not-updated-lintian-page fool you. My packages hasn't got any RC bug in unstable or testing and they are all updated.
What I really want for Christmas is Task and Skill step finished. That will look great under Christmas tree :)
Thanks in advance.

Your eternal applicant, luciano

No honking today; I guess there just isn't a big German population in Montreal. But, y'know, fourth place is pretty damn good, Portugal! Nothing to sneeze at. Still ahead of Brazil, for what it's worth. Tomorrow's the big finale, of course. The Paramount Famous Players on Ste. Catherine downtown is going to have a live showing, free for the first 300 people. I dunno... I guess it could be fun, but it seems a little impersonal. I think I'll be watching from Niko's again. It's easy to walk to Little Italy, or Barouf, from there. tags: montreal world cup germany portugal

Grillr I spent the day putting together household furniture. We stopped by Canadian Tire on Tuesday to buy lawn furniture, and we got a shipment from Ikea on Wednesday. This afternoon cleared out a lot of cardboard boxes from our house. First up was Amita June's big girl bed, which she got as a present for her month birthday. Yeah, Amita turned the big one-oh yesterday (10 months!), and although we've been doing wp:co-sleeping, we want her to start learning to sleep in her own bed. (Most co-sleeping babies want to move out after about 1 year.) She got a toddler bed, which is actually pretty cute, and fits perfectly in her room. Building Ikea furniture isn't really all that fun. First, they optimize for shipping size and storage, not for ease of building (or stability), so you get some really shaky stuff. Second, the instructions have no words -- assumably to avoid translation costs -- so you have to interpret their graphical V lapuk into some kind of reasonable instructions. Fortunately, just about the time I finished building it, Maj and Amita came home from a walk. Amita had just fallen asleep, so we put her in to see how it fit. Looks pretty good to me! After that, I watered my new lawn. The grass seeds I spread on Tuesday are coming up in teensity-tinesity leaves. Huzzah! Then I turned my attention to the wt:Muskoka chairs we got from Canadian Tire. These turned out to be a lot easier, and they were made from cedar wood, so they were pleasant to work with. Maj had invited over some friends for grilling, so she went to the store to buy food while I worked on the Muskokas. The baby hung out with me outside in her playpen. The chairs turned out great, and we had a nice grill. Brenda, Parise and Tony all came over. Brenda and Tony are librarians, and Brenda and Parise grew up together in wt:Moncton. The Muskokas were a hit; here are Brenda and Amita enjoying one. tags: ikea bed amitajune grill muskoka chairs lawn grill

Fireworks I can hear right now the dull thump thump tha-thump-thump of fireworks going off down at La Ronde, the amusement park in the middle of the St. Laurent River. They're the hosts of the International Fireworks Festival, which happens every summer. It's one of the great things about living in Montreal -- fireworks every Wednesday and Saturday from early June until the end of July. The festival is a competition -- national pyrotechnics teams each provide a half-hour long show on one of the nights, and then at some point after the festival they decide on a winner (I think... I've never actually checked who "won"). The fireworks are first-class, and it's just fun to have explosions over the city all the time. Tonight's team is wt:South Africa -- it's the first time there's been an African national team. Go SA! tags: south africa la ronde international fireworks festival pyrotechnics montreal fireworks

Best show ever One of the best music shows I ever went to was a "surprise" event by Camper Van Beethoven at the now-defunct Mint Platter record store on Telegraph Avenue in wt:Berkeley, California around 1990. Probably one of the next best music shows I ever went to was a surprise (for me) when Maj took me to see CVB at the Just pour Rire Theatre in Montreal in 2004, one week after we were married. (The band had recently reformed, and that night their equipment was stolen out of their tour bus in Mtl. Such a shame.) I'm just thinking about it because so many of the shows I love are on the etree section of the Internet Archive. Secret message to every taper I crabbed out because their big boom mike was blocking my view of the stage: sorry. You were right. Thanks. And what reminded me of that? The NPR Live Concert Series, aka All Songs Considered. Man, there's a lot of good music in there. tags: live music archives etree camper van beethoven

One So, has anyone offered Kyle Macdonald of One Red Paperclip a marketing job yet? Guy knows his marketing. tags: one red paperclip kyle macdonald

Bignose strikes again I'll be honest -- most of the time, I totally don't understand fellow piglogger Michael Bakunin's blog. Here's an excerpt from Gasoline: FD: small short position in one US refiner, and thinking about crack spreads. Does that mean something to some species of animal? I dunno. tags: michael bakunin piglog gasoline

Wouter Verhelst wonders why you would use a firewall config tool (apart from a GUI) instead of writing iptables rules directly. While I do just use a couple of iptables statements in a shell script here on my laptop, this is not manageable for larger networks IMHO. In fact, I wrote my Pyroman firewall admin tool for the very reason that it replaced an existing iptables script which was a pain to maintain. I'm talking 300-400 lines here. Four networks, two failover firewalls, a dozen of servers in the DMZ network some of which with extra access rights into the internal network (such as accessing the LDAP directory). And no full-time admin to take care of them. So I needed a firewall script that everybody can edit and that won't fail miserably when they make a mistake. A script with extensive error checking and that prevents people from locking themselves out. With an easy syntax. The first approach was in Perl, and already worked quite good. The rewrite then was in Python, and the users (read: fellow volunteer "admins", that don't know the firewall by heart as I do) liked it a lot. They now could add new hosts and services without depending on me to update the firewall. This is a configuration file they'll immedeately understand:

# add the web server
add_host(
        name="web",
        ip="10.100.1.2",
        iface="dmz"
)
# offering, well, web service.
allow(
        server="web",
        client="ANY DMZ INT",
        service="www ssh ping"
)

In contrast to any pure iptables script. It also helps to require them to commit their changes to a SVN repository (for getting the changes synched to the failover firewall) - that way you have version control and undo.

Martin F. Krafft blogged about how to rollback firewall changes in the case you managed to lock yourself out from the box It's even easier if you use my Pyroman firewall config tool. (apt-get install pyroman). If you run pyroman safe it will execute the new firewall rules - and if you don't type OK within 30 seconds, it will undo all changes. Note that it can also restore to a configuration set by a different firewall app. (It just restores the old iptables state and feeds it back to iptables - it will support anything your iptables version does.) Oh, and it's much faster than the other firewall scripts I've tested so far, since it doesn't spawn hundreds of iptables processes, but only one iptables-restore for setting the new rules in one transaction. Check the web page for other benefits; should just work on any Linux distribution with iptables and python (read: every). [Update: Martin, I was referring to the instructions you gave, to adding an at job and then running atrm to accept the changes. Yeah, what you script does is basically the same what mine does for rollback.]

• East Campus is full of pyros (”could you please put out the carpet?”).
• Microwaving motherboards is actually not a very smart thing to do.
• Always bring multiple printouts of your GPG fingerprint to hacker parties (if you don’t have business cards with it).
• There are lots of fun toys in the Media Lab.
• Train conductors don’t actually read your tickets.
• Trains are almost always late.
• Falling down staircases in the dark at concerts hurts.
• It’s important to Love Your Beaver.
• MIT will kick your ass, get used to it.
• When you lose your phone card PIN, you have to go back to the same store you bought it at.
• It would have been smart to leave extra space in the suitcase for all the extra stuff I brought home that I didn’t bring there…
• Fear the ever-expanding Wiki People in the seedy underbelly of boston-soc!
• Acetarium parties don’t have ending times.
• The MIT Press loading dock sale is a veritable treasure trove.
• Best. Hack. Ever.
• Nothing ever works out quite as planned. Solution: plan less.

I'm doing too many projects. I need to step back from most of them ASAP. I just don't want them to dwindle, but prosper... I really need to find more contributors for

• LaySVN, Layered Subversion, a svn mod written for storing the configuration of non-identical servers in SVN (read: servers that have some configuration parts in common, some differ) and probably of use for other cases.
  I've recently started a rewrite of LaySVN for speed reasons; you can't work on a per-file base with SVN but need to plan ahead a lot
• Pyroman, a firewall tool featuring a IMHO nice configuration language and which is very fast due to using iptables-restore, and it has rollback on errors
• SSDDiff, a diff tool for XML which can handle complex cases very well. Some say it's doing a "semantic" diff, actually. The "fast" (approximative) mode needs some love, the prototyp app IO needs to be redone (i.e. output filename parameters), XML attribute changes aren't reported yet in all output formats. I've also done some nice HTML diffs with it, that could be made a separate HTMLdiff application.
• Debtags central database needs to be rewritten to fit our newer requirements (e.g. moderation of edits or specific tags), and moved to a new server (old one still being woody)
• musicsquirrel (unreleased), a PyGTK duplicate finding tool using TRM ("musicbrainz") signatures, could need some magic like duplicate album detection (by "clustering"), and a UI to mass-select duplicates accoring to some rules (e.g. kill all duplicates found in the "unsorted" folder, if there is a properly tagged version in some other place)
• SELinux-Basics, a package to help getting SELinux working, has some basic sanity check shell scripts for a fresh SELinux system. These should be rewritten in OOP fashion with python or so, and extended with some extra checks.
• SELinux on Debian needs more adventurous people testing and using it, fixing policy to match Debian needs, writing new policy for new services, writing tons of documentation, doing some pretty install scripts and fixing some upstream bugs (module linking still not working). And making it as easy to use as AppArmor claims to be, because SELinux IS better and should be used instead.
• ISL3893, a wireless AP chip with a linux-based SDK available, is finally receiving some development. Too bad I can't devote any time to it. It would be cool to bring it up to par with famous OpenWRT.

Oh, and half of above projects need a fancy web design and an icon. Anyway, I should basically turn off my computer for the next two months and refrain from going online. :-( I know that I won't have the discipline to do so... And there are oh so many projects still only existant in my head that I'd really love to do sometime. One involving new search technologies with tags, bringing together directories like DMoz, tag based stuff like del.icio.us and "traditional" text search engines. Definitely the stuff the Web 2.0 is made out of (read: hype). But when I'm done with my diploma this new dotcom bubble is probably over, too... :-(

Today is an special day.

One year ago we (yes, you and me), started a beautiful path together. A long path with wisdoms and mistakes. I learned about Debian and you about correcting me, but both learned to wait each other.

Dear Pyro, for not to many years together, with this wonderful relation ApplicationManager-Applicant, I say you: Happy Anniversary!



PD: don't get angry, I'm just joking (c:

Pyroman, my firewall tool for multi-network firewalls, is now in Debian unstable. Or will be, on the next mirror push. Thank you, ftp-masters. I thought you were, like, inactive. ;-)

Pyroman is now hosted on alioth, and uses Debians subversion server. I just did a new pyroman release, version 0.1.2. This is just an interim beta release, a version 0.2 will follow soon. New in this version is: Detailed error reporting: when a firewall rule is rejected by iptables (e.g. because you specified an invalid port range pyroman didn't detect), it will give you the corresponding filename and line number! Automatic rollback: Pyroman will undo any changes to the firewall if either any rule is rejected by iptables, an exception in pyroman occurs or the user fails to accept the changes within a configurable time limit (e.g. because he just broke his ssh connection...) So pyroman is even cooler now! ;-) On the TODO list: add a no-confirm switch for use at system bootup, code cleanups and a iptables-version test, so you can add rules that need a specific iptables version (such as string matches for bittorrent).

So, I’m heading back out to Israel for work, and it turns out I have a 12-hour (!) layover in Amsterdam. I’m arriving at 8AM next Tuesday (Dec. 6) and won’t depart until 7:45PM. That gives me a full day to see the city. If any Debian people would like to meet up in Amsterdam that day, please drop me an email.

I just finished rewriting an old firewall tool from Perl to Python. Since it's in Python and about firewalling I dubbed it Pyroman. I investigated a dozen of firewall-tools before, including shorewall and firehol. Each had it's stength and its weaknesses. After writing iptables rules in a shell script every now and then for a more complex project (with like 6 networks of which 3 are bridged together) and two dozen of differently configured hosts, NATs, VPN, everything. My predecessor had written a shell script to configure the firewall, but this was really bad to maintain. So I ended up writing a perl application to generate the rules from a modular configuration (read: usually one file per host, containing a perl hashmap) Well, after happily using this script for two years, I dedcided it's about time to rewrite it and document it extensively. I chose python for the rewrite. You can get the result here: Pyroman 0.1.1. The good:

• Written in pretty python
• Extensively documented (Python docstrings)
• Much faster than sh+awk based solutions
• Really easy syntax to add hosts, nats
• You can add custom iptables rules when needed
• Designed for complex networks
• Lots of verification checks done before execution
• Designed to use the same configuration files on multiple hosts (e.g. failover firewalls or the destination host itself; it will detect if you are talking about a local or a remote host
• It will report file name and line number on parser errors, verification errors and execution errors.
• If any rule fails to setup, a rollback will occur, restoring your previous firewall
• (will likely have auto-rollback if you lock yourself out in the next version with a simple timer)
• Extensive configuration example

The bad:

• Not yet tested in production
• Doesn't completely hide iptables complexity (some core config files are just containing iptables rules, but why invent a new syntax?)
• Only iptables, no TC/Shaping, no IPsec, proxy arp setup, VPN, ifconfig (I use other tools for that, e.g. heartbeat)

To tease you a little more into testing, here's an example host configuration: ("dmz" is an interface alias - where the web server is connected to -, as are "INT", "DMZ" and "ANY" for clients on these interfaces)

"""
A really simple webserver configuration.
These examples are just boring... ;-)
But without NAT they would be even more boring. ;-)
"""
# web server
add_host(
        name="web",
        ip="10.100.1.2",
        iface="dmz"
)
# offering, well, web service.
allow(
        client="ANY DMZ INT",
        server="web",
        service="www ssh ping"
)
# internal hosts may access FTP, too
allow(
        client="INT",
        server="web",
        service="ftp"
)
# setup NAT
add_nat(
        client="ANY INT",
        server="web",
        ip="12.34.56.80"
)

(Yes, this is a python script. No, you probably won't care to write your configuration in a programming language, will you?)